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FCC Censors/Censures 


Packet Radio 


Tom Clark, W3IWI 


January 30, 1991 


fl meet anumber of packet BBSs on 
the east coast received citations 
from the FCC’s Norfolk (actually Vir- 
ginia Beach) Field Office which may 
well spell the end to much of amateur 
packet radio. According to Jim, 
WA4AONG the following packet BBSs 
(and perhaps others) are involved: 
N3LA, WA3TSW, KA3CNT, KA3T, 
WA3ZNW, W3IWI, WA4ONG, 
WBOTAX and N4HOG [my copy of the 
citation has not yet arrived in the mail— 
the details in this message are taken from 
a copy WA4ONG faxed to me]. 


The letter dated January 25th from 
Mr. J. J. Freeman, Engineer in Charge at 
the Norfolk Office, to WA4ONG states: 


Announcement 


Eric Williams, WO6CMU 
NCPA President 


for the meeting will be: 


* NARC 220MHz reallocation plan 
¢ Election of directors 


NCPA General Meeting 


he Annual general meeting of the Northern California Packet Association 
will be held on Saturday, April 27th at 10:00AM in the board room of the 
Contra Costa County Water District, 1331 Concord Avenue, Concord. Talk-in 
will be on 147.735(-). All interested parties are welcome to attend. The agenda 


« Summary of board actions and plans 


“T have received a report that indicates 
you may have operated your amateur 
radio station, call sign WA4ONG, in 
violation of Section 97.113(a) of the 
Commission’s Rules. It appears that you 
used the Amateur Radio Service to 
facilitate the business activity of The 
Coalition To Stop U.S. Intervention in 
The Middle East. 


“Specifically, on or about January 5, 
1991 you received a packet radio mes- 
sage originated by amateur radio station 
WA3QNS. You then transmitted this 
packet radio message to another amateur 
radio station. The message was:” 


Here appears a copy of the message 
sent by WA3QNS@N3LA.PA 
originated at 22:22z on Jan.5 with the 


Continued on page 5 


vorinern Calitornia Packet Association 


Editorial 


Glenn Tenney, AAGER 
t’s amazing what happens when you say that you’!l help 
out a little bit... When the NCPA board went looking for 
someone to take on the editorship of this newsletter, Larry 
Kenny, WB9LOZ, and I each agreed to take on part of the 
duties. 


Mike Chepponis, K3MC, has done such a fine job that it 
looks to be an insurmountable task to do even a fraction of what 
Mike has been doing since the first issue. I want to thank Mike 
publicly for the terrific, yet usually thankless, job that he’s been 
doing. Most readers of a newsletter don’t understand how 
much effort it takes to edit. Larry and I are each only doing a 
small part of what Mike had been doing, and let me tell you that 
it is a huge job. We hope that over time we’ll get the hang of 
it and the newsletter will meet your expectations. 

Buta newsletter isn’t just editing, typesetting (thanks to Eric 
Williams, WD6CMU), and printing. Our newsletter is based 
on articles from you. As you’re reading this, why not jot down 
that little idea or comment you had yesterday. Even though you 
know all about whatever, there are many people out there who 
would like to read about it. Don’t be worried about spelling, 
grammar, or punctuation. Ill try to go through and tweak 
submitted articles. Don’t worry about what someone might 
think. We are our own worst critics. 

In this issue, you’ find lots of information on various facets 
of packet radio. There are regular columns, features, and even 
something that might make you think... 

Producing this issue has taken even more time and effort 
than I thought. A few days before the deadline for this issue 
we were many pages short. Now, that we’re a bit late, we have 
almost enough for half of the next issue and I’m faced with the 
awful task of splitting an article across this issue and the next 
issue. I don’t know how K3MC did it. Thanks again, Mike! 


Speakers Available... 


The NCPA maintains a list of 
amateurs willing to speak to clubs 
and organizations about various 
aspects of amateur radio. We 
have speakers available for talks 


on packet radio, emergency com- 
munications, the National Traffic 
System, TCP/IP, AMSAT, etc. For fur- 
ther information contact Allan 
Chapman, W6MEO @ WD6CMU. 
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Apple Petitions FCC 


For Use of Radio Waves For Data Transmission by All Computer Makers 


(Editor's note: Many of you may 
have seen this press release, or even the 
full petition. What do you think about 
this? Let us know...) 


Washington, D.C 
January 28, 1991 


pple Computer, Inc. today filed a 

petition with the Federal Com- 
munications Commission (FCC) that, if 
approved, would let computers transmit 
and receive information over radio 
waves instead of through a wired net- 
work. The petition asks the FCC to allo- 
cate a part of the radio spectrum so that 
all computer manufacturers be permitted 
use of radio waves for wireless comput- 
ing. Apple believes that approval of the 
petition is an important step in the estab- 
lishment of the next generation of per- 
sonal computing. 


Apple’s petition paves the way for the 
establishment of a new class of data com- 
munications, called Data Personal Com- 
munications Services (Data-PCS). If 
Apple’s petition is approved, personal 
computer users in the future will be able 
to communicate with other users and 
with computer peripherals within a 
building or a campus over radio waves. 
This innovation would eliminate the 
need, in many cases, for local com- 
munications to travel on wired networks. 

“With the rapid advances in portable 


computing and wireless communica- 
tions, we believe it is essential that com- 


puter users have access to this vital com- 
munications resource in the future,” said 
John Sculley, Apple’s chairman and 
chief executive officer. “Wireless net- 
works will change the nature of informa- 
tion tools, making them as mobile and 
spontaneous as the individuals using 
them. 


“Apple’s action, which will benefit 
all personal computer users, is motivated 
by a desire to ensure that the United 
States will have made the most forward- 
looking public decisions, allowing wire- 
less networking to become a reality,” 
Sculley added. 


Specifically, Apple petitioned the 
FCC to allow computer communications 
exclusively on 40 MHz of the radio fre- 
quency bandwidth between 1850-1990 
MHz to transmit data at high speeds (for 
example, 10 megabits per second) over 
short distances (up to about 150 feet). 


"The convergence of wircless com- 
munications and computers will dramati- 
cally change the nature of computing," 
said David Nagel, vice president of 
Apple’s Advanced Technology Group. 
“For example, students and teachers 
would no longer be confined to a rigid 
classroom set-up. Instead, computing 
and communications--and therefore 
learning--could happen any place. Users 
in the workplace would enjoy similar 
advantages. Employees would be 
liberated from the constraints of physical 
networks, which would enhance 


1991 Bay Area Amateur Radio 
Flea Market Schedule 


11 Flea markets at Foothill College (Los Altos Hills) are + 
through the courtesy of the operators of the Foothill 
Electronics Museum of the Perham Foundation. Note: Loca- 
tion Change... Parking Lot C this year, just down from the * 


Museum. 


e March 9—Amateurs donation to Palo Alto Red Cross 
e April 13—SPECS Repeater Association 
* May 11—EMARC Electronics Museum Amateur Radio 


Club 


e June 8—PAARA Palo Alto Amateur Radio Association 


creativity and personal productivity,” 
Nagel said. 


This type of “spontaneous” or “ad 
hoc” local area networking would sup- 
plement today’s wired network con- 
figurations, which typically consist of 
telephone lines, coaxial cables, and fiber 
optics. The cost, particularly the capital 
cost, of hardwiring a building is high and 
then users are restricted as to when, how 
and where they can use their computers 
to move data. 


Apple recognizes that radio spectrum 
is scarce and in high demand. Consider- 
ing this, along with the intense activity 
being focused on proposals for new voice 
communications services, Apple is re- 
questing that the FCC move quickly in 
giving equitable consideration to data 
communication when determining future 
bandwidth allocations. 

“We’re urging the public to support 
Apple’s appeal that the allocation of 
radio spectrum go beyond voice com- 
munications to include an appropriate 
emphasis on data communications,” 
Sculley said. “Our hope is that computer 
users will view the allocation of the radio 
spectrum for wireless computing as 
Apple does—as an important step in ad- 
vancing the future of personal computing 
technology.” 


Apple and the Apple logo are 
registered trademarks of Apple Com- 


puter, Inc. 
EOF 


July 13—FARS Foothill Amateur Radio Society 
* Aug. 10—Perham Foundation 
Sept. 14—SPECS Users’ Group 


Sellers $10 (for two spaces) Buyers FREE. Coffee, donuts, 


hot dogs & pop as always. Talk in on 145.27/repeater or 


224,36/repeater Gates open at 6:30 a.m. Come early to get a 


seller space!!! 


Questions? leave a message for Ted, N6IIU@N6IU-1 


Amateur exams have been moved to Sunnyvale. For more 


24 /hrs. 


information call Sunnyvale VEC (408) 255-9000 
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Editorial Regarding the W3IWI “Incident” 


,AAGER 


k, now you’ve had a chance to 

read about this, if you hadn’t 
heard about it before. The March 1991 
issue of QST has an editorial by David 
Sumner, K1IZZ, on this incident. His 
editorial begins by claiming two “facts.” 
His first point being that promoting the 
use of a 900 telephone number is a viola- 
tion of FCC regs. On the surface, I would 
agree with that, but one could easily take 
an extremists view that even mentioning 
an 800 number could be a violation. 
Sumner’s description of a 900 number is 
that it is “the kind that costs you money 
to call.” Well, an 800 number might not 
cost the person making the call, but the 
recipient of the call pays for for the call 
(the carrier receives the money). Would 
Sumner then say that mentioning an 800 
number violates the regs? 


Sumner then makes the claim that be- 
cause the message was addressed to 
“ALL@USA” it also violates the regs 
since it “had nothing to do with Amateur 
Radio” and was “a one-way communica- 
tion falling outside the definition of ‘in- 
formation bulletin’” and that it therefore 
"constituted broadcasting”. This bothers 
me much more than does his first. 


Reviewing the definitions in Part 97 a 
bit further finds that such a message 
could not be construed as being broad- 
casting. Broadcasting is defined as 
“Transmissions intended for reception 
by the general public.” A packet mes- 


Glenn Tenn 


sage originated by aham ona ham PBBS 
is definitely intended for reception by 
other hams, and not the general public. 


Sumner specifically says that “mes- 
sages addressed to ‘ALL’ are in effect 
broadcasts.” If Sumner is correct, then 
any message not addressed to a specific 
person would be a broadcast. Please note 
that broadcasting per se is not illegal, just 
that a broadcast must meet certain 
criteria to be legal. How many PBBS 
messages have you seen that are long or 
short, but addressed to some smaller sub- 
set of ‘ALL?’ How many of those mes- 
sages made you think and respond? A 
PBBS, or even an email network, is a 
conferencing system that is a bit different 
than a voice repeater. On a voice 
repeater it would be unlikely to just say 
something hoping that someone would 
respond. With a teleconferencing sys- 
tem, that is the norm. Does that make it 
broadcasting? I think not. Somehow, 
broadcasting tends to include the expec- 
tation of remaining a one-way transmis- 
sion, whereas a PBBS message expects 
some response—only the person 
responding isn’t known ahead of time. 
Should we stop using ‘ALL’? There are 
definitely messages that shouldn’t be ad- 
dressed to ‘ALL’ (or even a subset of 
ALL), but not for this reason. 


This whole incident raises other con- 
cerns though. I think everyone can agree 
that if a ham originates an inappropriate 
or illegal message, that ham should be 


The End or the Beginning? 


Fred Silveira, KERAU 


D> you remember your first ex- 
perience soloing behind the 
wheel of an automobile? The command 
of mobility, seemingly frictionless 
“flight,” the beckoning horizon—it was 
all there. 

First time packet offered similar 
parallels—the keyboard command, 
seemingly an endless myriad of bulletins, 
and the beckoning of a network which 
could send messages to all parts of the 
world. 


At some point came the realization of 
what the awesome responsibility was to 
glide a several ton vehicle down the road- 


way. Packet carries its own respon- 
sibilities. With a worldwide forwarding 
network it is important all of us observe 
that our messages and bulletins meet the 
rules and regulations of Federal Com- 
munications Commission law. 


In past years, bulletins have for- 
warded through the networks extending 
from sale of telescopes to boats—all il- 
legal under rules governing amateur 
radio communication in that their subject 
matter was not confined to the realm and 
sphere of amateur radio. When dis- 
covered, they were deleted and service 
messages sent back to the originating 
stations advising of such. 


cited. But, what should all other hams 
do? If you have a packet station up (not 
even a PBBS, you just have digipeating 
enabled), and a “bad” message gets 
repeated through your station should you 
be liable? I think the answer should be a 
very clear and explicit NO. The ques- 
tions raised by this incident are: (1) Will 
the FCC cite others in the future, and (2) 
how can we get the FCC regs 
changed/clarified so that this won’t hap- 
pen again? 

The other concern that this raises is: 
Do hams have any constitutional rights 
on the air? Do we have first amendment 
rights? Could this incident have been a 
problem because it was anti-war? I 
doubt some of these questions will be 
answered, but it does make one think. 


What will be the result of this: If you 
run a PBBS, will you now decide to 
personally read and screen every mes- 
sage going through your station? Will 
you close down your station? Will you 
Stop digipeating? Will you give up 
amateur packet all together? Will this 
squash amateur packet radio? Will this 
cause many of us to put our energies into 
Part 15 packet where we don’t have to 
worry about message content at all? Or, 
will someone submita request to the FCC 
to change the rules? Maybe it’s time to 
wonder if it continues to make sense to 
deprive us of our constitutional rights on 
ham frequencies. 

EOF 


The problem culminated recently 
when the FCC cited several bulletin 
boards on the East Coast for forwarding 
a bulletin originated by a user soliciting 
funds for a political organization. 
W3IW1 issued a series of bulletins titled 
“URGENT” detailing the matter. They 
are printed elsewhere in this issue. 


As it applies to the future of packet 
network forwarding, it is incumbent 
upon all of us to review, consider, and 
reflect upon the ramifications of this 
recent event. 


EOF 
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The Downlink 


FCC Censors/Censures Packet Radio 


Continued from page I 


BID #21035_N3LA, Subject: Call This 
Number ASAP. The message listed the 
business telephones and fax numbers for 
“The Coalition” as well as a 1-900-xxx- 
xxxx number to call to “register your 
voice” I won’t repeat the bulletin here, 
because repeating the bulletin would 
make it illegal to send this message! 


“This activity was a facilitation of the 
business affairs of the Coalition to Stop 
US. Intervention in the Middle East and 
therefor [sic] in violation of Section 
97.113(a).” 


The FCC citation then contains the 
boilerplate demanding a response within 
10 days explaining circumstances and 
correct actions, and then closing with a 
chilling “to determine what, if any, enfor- 
cement action is required to insure cur- 
rent and future rule compliance” and a 
statement that future transgressions will 
bring fines and/or license revocation. 


That’s the facts. Ill now discuss some 
of the implications and recommended ac- 
tions. 


The Implications 


The implications of the action by the 
FCC’s Norfolk Field Office are absolute- 
ly appalling. What is implied is that each 
and every station in a store-and-forward 
network is responsible for the actual mes- 
sage CONTENT passing through each 
node. The BBSs were cited because their 
calls were in the message header “audit 
trail.” The FCC’s action states that each 
BBS SYSOP is personally responsible 
for the “correctness” of all messages 
merely passing through his system. Here, 
the W3IWI mail switch handles about 
10,000 messages per month automat- 
ically. There is NO WAY that I can 
vouch for every bit that passes through! 


If the FCC had instead gleaned its 
information from on-the-air monitoring, 
then all the THENET/NETROM/ROSE/ 
TCPIP/DIGIPEATER switches handling 
the message would have been equally 
culpable! The implication of the FCC 
action is that a node control operator 
must read all information and be 
prepared to shut the system down at the 
first hint of an “inappropriate” message. 
It’s hard enough to watch the information 
passing on 1200 BPS links—imagine the 
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impossibility of “censoring” 56 KBPS or 
faster channels. 


In future networks where redundant 
channels exist, it is quite possible that a 
given message will be fragmented and 
parts of it sent via several parallel paths. 
The message may exist as a complete 
entity only at the ends of a virtual path. It 
would be impossible to implement the 
censorship the FCC seems to be demand- 
ing with such a network, so the “legality” 
will interfere with development of new 
technology. 


Consider another recent develop- 
ment: amateur packet radio satellites. 
PACSAT is licensed by the FCC with a 
US trustee and a cadre of US sysops. 
PACSAT is, in essence, a flying BBS 
with the sysops on the ground. In order 
to screen out “offensive” messages, a 
ground-based SYSOP has to use a radio 
channel to verify message CONTENT. 
But the FCC letter says that the very act 
of reading an “offensive” message on the 
radio is illegal. If the Norfolk FCC action 
is allowed to stand, the logical implica- 
tion is that PACSATs must be tumed off! 


A number of us have discussed such 
issues with responsible individuals at the 
FCC in Washington ever since the first 
fledgling days of packet radio, The signal 
that the FCC sent was that the sole 
responsibility for the CONTENT of a 
message lays with the ORIGINATOR. 
The actions of the Norfolk Office seem 
to indicate a new policy has been adopted 
which effectively kills packet radio. 


Or—perhaps—the Norfolk Engineer 
in Charge who issued the citations was 
offended by the particular message and 
chose to take out his frustrations on all 
the “King’s Messengers” who brought 
the message to him? 


W3IWI Comments and 
Recommendations 


It is ironic that the WA3QNS message 
that brought down the wrath of the FCC 
a number of the BBSs that “touched” his 
message brought a very vocal response 
from the packet community informing 
him that 


(1) 1-900-xxx-xxxx are in fact commer- 
cial ventures designed to raise money 
and that a call to the number would 
cost the caller. 


(2) The subject message was probably in 
violation of 97.113(a) and probably 
illegal 
Personally, I have been silent (but 

very frustrated) that about the 10% of 

bulletins addressed @USA (or 

@ALLUS, @ALLBBS, etc.) that are in 

poor taste. I have grown tired if blather 

about censorship, First Amendment 

Rights and the incredible volumes of hate 

mail. WA3QNS, by his statements and 

by the responses to his statements from 
other folks, has been one of the causes of 
this frustration. I have longed for the 
return to normalcy with messages on 
technical topics and personal com- 
munications. I have found it frustrating 
to pay the electric power bill and pay for 
the W3IWI hardware for others to 
engage in marginally offensive “Free 

Speech.” I have wished that the 

(ab)users of @USA would have exer- 

cised more discretion with self-censor- 

ship. 

But I have gritted what teeth I have 
left and avoided being a censor. Now, the 
FCC’s CENSURE has left me with no 
alternative than to be a CENSOR. 


Until the FCC tells me that I can do 
otherwise, I will only release @USA 
messages that I personally screen and am 
willing to stake my license on. The 
priority on my time is such that I don’t 
expect to have time to screen @USA 
bulletins. Any complaints about my 
decision will be sent to /dev/null. 


For the vast majority of you who do 
not abuse the system, I’m sorry that this 
situation has come up and that your 
ability to “fan out” information will be 
hindered. Since there have been very few 
instances of “offensive” personal mes- 
sages, I'll take the risk of keeping all 
other packet mail flowing here and I hope 
the other BBS SYSOPs do likewise. But 
PLEASE exercise self-policing. The 
BBS SYSOPs don’t want to be held 
responsible for YOUR words. 

The ARRL has already been informed 
about the Norfolk citations. Because of 
the potentially devastating impact on all 
packet radio if the Norfolk situation is 
allowed to stand, I anticipate a lot of 
phone calls to be made in the next few 
days! 

73 de Tom, W3IWI 


EOF 
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Northern California Packet Association 


A Blow-By-Blow Account of the 1991 TAPR 


Annual Meeting 


Paul Williamson, KBSMU 


(Editor's notes: I haven't seen amore 
complete, informative, and well done set 
of notes of a ham or any meeting. We're 
including Paul’s notes, with his permis- 
sion, virtually complete and with the 
most minimal editing. This article is 
chock full of information, but we just 
didn’ t have enough room in this issue for 
all of it. This is the first part of Paul’ s 
notes. Look for the rest of this fantastic 
reporting job in the next issue. Enjoy!) 


he following is based on the notes 

I took during the TAPR annual 
meeting. Any mistakes are mine. On no 
account should you assume that this ac- 
count represents the official position of 
TAPR or anybody else. But I hope you 
find it interesting. 


The TAPR Annual Meeting was 
called to order by “Packet” Pete Eaton, 
WB9FLW, at 9:00 a.m. on 2 March 1991 
at the Inn At the Airport in scenic Tucson. 
The attendees introduced themselves; the 
usual suspects were present from all over 
the country. 


Bob Nielsen, W6S WE, new President 
of TAPR, announced the new Directors 
and Officers: 


President: Bob Nielsen, W6SW— 
also new director 


Vice President: Harold Price, NK6K 


Sec/Treasurer: Greg Jones, 
WDSIVD—also new director 


new director: Jerry Crawford, KTUPJ 


Greg Jones, WDSIVD, presented the 
proposed agenda for the meeting. 


Bob Nielsen, W6SWE, introduced 
Bob Hansen, the new editor of the PSR. 
Bob Hansen stated that, as always, he’s 
looking for articles for the PSR. If you’re 
doing something interesting locally, 
even if it seems like old hat to the local 
crew, it can make an interesting PSR 
article. Examples: database applica- 
tions, video, 9600 bps interfacing, 
regional activities, networks with special 
features, DX nodes, WX nodes. Ghost 
writers can be provided if you’re afraid 
your prose isn’t ready for prime time. 
PSR also accepts would-like-to-get- in- 
touch-with and help-wanted notes. PSR 


would like to receive as many local 
newsletters as possible. 


Question: Would it be possible for 
PSR to routinely publish a list of local 
and regional groups? Answer: Sure. 
Everybody please tell me about your 
local and regional groups, and PSR will 
print it. 

The one and only Heather Johnson 
(TAPR office staff and “the Mother of all 
Johnsons”) was introduced. She wel- 
comed everyone to Tucson, and 
apologized for the weather (it was rain- 
ing). She announced the hospitality suite 
in the hotel, where she’d be holding court 
to sell various merchandise and accept 
membership renewals. Kit prices may be 
going up, so she urged us to buy now. 
TAPR office hours will be more strictly 
observed: 10:00 AM to 3:00 PM Tuesday 
through Friday. The answering machine 
will take your message other times, but 
Heather would rather speak to you in 
person (and you'll enjoy it more too - 
Paul). 

Pete Eaton, WB9FLW, presented a 
corsage to Heather, in appreciation forall 
the hard work. He described her as 
TAPR’s biggest asset and Secret 
Weapon. 


Harold Price, NK6K 
Microsat status report 


This is the first TAPR meeting since 
the Microsats became operational. Four 
microsats were launched; one was half 
funded by TAPR out of the proceedings 
of TNC-2 sales. The satellites were 
designed by AMSAT, but the funds came 
from various organizations around the 
world. 


Microsats serve as floating BBS sta- 
tions, and they are optimized for that 
application. About 9 inches on a side, 
they weigh 22 Ibs and carry 3 transmit- 
ters, 6 receivers, a NiCd battery pack, a 
computer with 8 megabytes of memory, 
serial ports, and a telemetry and control 
system. A slide of AMSAT OSCAR-16 
was shown. These satellites are much 
simpler than AO-10 or AO-13, since the 
payload is basically a computer, and the 
orbit is low. They contain no moving 
parts. Attitude control is required to con- 
trol thermal problems: hot on one side 


and cold on the other is only good for 
McDonald’s BLT’s. The attitude control 
system consists of magnets which tend to 
align the Z axis, a solar windmill which 
tends to spin the satellite faster and faster, 
and lossy hysteresis rods which regulate 
the spin rate by dissipating energy. The 
photovoltaic panels generate an orbit 
average of about 8 watts, and the battery 
pack levels the voltage over the orbit. 


The satellites were originally sup- 
posed to be stamped out like cookies 
from a cookie cutter, but it didn’t work 
out that way. Every satellite was dif- 
ferent in some way. A slide of WEBER- 
SAT OSCAR-18 shows the penthouse 
(or attic, depending on who you ask) 
containing a Canon CCD-based video 
camera. The camera experiment 
samples the NTSC output from the har- 
dened stock camera assembly. This per- 
mits color to be recovered from the 
sampled image. For example, Franklin 
Antonio, N6NKF, has written a program 
that extracts good quality color images 
from WEBERSAT pictures. Unfor- 
tunately, no good pictures have been 
taken since WO-18 was launched. 


A picture of DOVE OSCAR-17 is 
dominated by Junior De Castro, 
PY2BJO, a major benefactor of the 
Microsat program. DOVE transmits on 
2 meters FM through its outsize 
downlink antennas. The primary mis- 
sion is a digital voice encoder intended 
for educational uses. 


A picture of a partially assembled 
Microsat illustrates the stacked slice 
chassis concept. Another picture shows 
the wiring harness: a simple 25-pin rib- 
boncable. Various analog voltages from 
telemetry points are multiplexed onto 
just one of the wires, under the control of 
a serial local-area-network that logically 
interconnects the stacked modules. 


A picture of the AMSAT lab shows 
key workers Jan King and Jeff Zerr. 
Many other credits for work on design, 
flight integration, and software were 
recounted. A picture of preparations for 
thermal vacuum test illustrates the kind 
of special resources that can be obtained 
through connections. Some of the lead- 
ing enthusiasts have been “doing satel- 
lites” since 1970, and in the meantime 


ne 
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Packet Radio Reaches New Heights 


Tony Bamberger, NOTYG 


(Editor's note: Tony's article was 
previously published in the September 
issue of QEX. The experimental work 
Tony is doing in the CDF Volunteer In 
Prevention program should be very in- 
teresting to our readers. This might also 
be the kindling for some hot new software 
or packet applications.) 


ecently I had the opportunity to 

be part of a demonstration put on 
by the California Department of Forestry 
and Fire Protection (CDF) for the State 
Fire Marshall’s conference at the 
Asilomar State Conference Grounds in 
Pacific Grove, California. The 
demonstration was two fold. First to 
show the operation of a new fire mapping 
system CDF is testing called “Loran- 
Plot,” and secondly the operation of the 
VIPCOM] communications bus manned 
by CDF trained Amateur Radio 
operators. 


The LoranPlot project was started to 
assist in the real-time mapping of the 
perimeter and area of a fire from the air. 
LORAN is a system of LOng RAnge 
Navigation in which pulsed signals sent 
out by two pairs of radio stations are used 
to determine a geographical position of a 
ship or aircraft using the time of arrival 
of the the signals. The LORAN naviga- 
tion system installed in CDF helicopters 
have provisions to collect the real-time 
Longitude and Latitude information via 
an RS-232 serial link. Utilizing a stand- 
ard “laptop” computer it is possible for 
the pilot or observer to start and stop the 
data collection when or where desired as 
well as add comments into the data file. 
These comments are usually simple 
descriptions, for example: “BARN,” 
“HOUSE,” “CAR,” etc. to add emphasis 
to the plotted data. Normally after com- 
pleting a plotting run it is necessary for 
the pilot to land the aircraft and take the 
computer to another location. Here the 
computer is hooked up to a plotter and 


TAPR Annual Meeting 


they have risen to positions of authority 
in their companies. Having a company 
bigwig fetching and toting cables makes 
a big impression on the other employees; 
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the information is plotted onto a standard 
topographical map utilizing additional 
plotting software on the laptop computer. 

Even though this system is far supe- 
rior to the old manual method of drawing 
on a map by hand while flying over the 
fire area, there is still a time lag in 
processing the data because the aircraft 
must return to its base where the com- 
puter can be hooked up to a plotter to 
view the information. With a fast 
moving fire the information is outdated 
before it can be plotted... 


Well at this point you’re probably 
saying “This is interesting, but what does 
ithave todo with Amateur Radio...” Well 
I’m glad you asked! Seeing a chance to 
try some experimental radio work, a 
group of hams from the CDF “Volunteers 
In Prevention” program came up with the 
idea of transmitting the ASCII data from 
the airborne computer down to the 
ground using Amateur Packet radio. The 
possibilities were endless for this type of 
communications. Not only could the in- 
formation be collected from the aircraft 
locally while it was flying overhead, but 
if it were necessary, the data could be 
relayed hundreds of miles using the 
Packet Backbone network. With this 
motivation in mind, here is how we made 
it work... 


The pilot, Fred Nunes (N6CYA) was 
using a 440 Mhz ICOM HT and a Heath- 
kit Pocket Packet TNC into an antenna 
off the bottom of the helicopter. The 
laptop would do double duty firstrunning 
the “LoranPlot” collection software, and 
then controlling the Packet TNC using 
the PROCOMM communications 
software. Prior to the actual demonstra- 
tion, a long distance data transfer test was 
successfully conducted between the 
helicopter base (at Alma fire station in 
the mountains above Los Gatos, Califor- 
nia) and the communications bus setup 
70 miles away at the Asilomar con- 
ference grounds. By linking through the 
Northern California Backbone network, 


this makes it easier to get cooperation 
from them! 


A picture of a Microsat with the hood 
open shows that the modular stacksat 
concept makes it relatively easy to ser- 
vice. (At least, that’s the theory. - Paul) 
A picture of UoSAT OSCAR-14 


we connected and successfully trans- 
ferred sample navigation plot data. 


For the live demonstration, Fred flew 
over the area of a previous fire while 
collecting the data from the LORAN 
using the laptop computer. After the data 
was collected, Fred “CONNECTED” to 
the Packet station onboard VIPCOM1 
and downloaded the plot data using 
PROCOMM. Two minutes later the 
transfer was completed, and Fred was 
free to plot another area or continue his 
primary mission of “fire suppression.” 
At this point the collected data (stored on 
floppy disk) was edited to remove the 
“CONNECT” and “DISCONNECT” 
messages and was then processed by the 
plotting software which plotted out the 
fire perimeter (with comments) onto a 
topographical map. Time from start to 
finish, 5 minutes from initial Packet 
“CONNECT” to plotted results... 


Was the demonstration a success? 
Judging from the applause and com- 
ments from the audience of State and 
Local fire officials, it was a resounding 
success! Amateur Radio once again 
proved the feasibility of new technology. 
In the future this system would work on 
State radio frequencies using commer- 
cial TNC’s, but the technology was 
proven using Amateur knowhow and 
equipment! After the demonstration, 
tours of the communications bus were 
given and the capabilities of Voice, Digi- 
tal (Packet), and Amateur Television 
were explained to the participants. Many 
of the officials were familiar with 
RACES, but were not aware of all of the 
capabilities hams could provide... 

Special thanks to: Fred N6CYA, Dick 
KB6MRM, Jim KA6YRK, Chris 
W6/G8HID, and Mike KB6PDA for 
making this all work. 

tonyb@novell.com 


N6TYG@N6TYG.#NOCAL.CA.U 


SA.NA 
EOF] 


provides a contrast. It weighs 60 kg, 
about twice as big as a Microsat. The 
wiring harness contains more than 400 
wires. It does contain more redundant 
subsystems than a Microsat; the Microsat 


Continued on page 15 
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Northern California Packet Association 


Book Review 


Pat Mulrooney, NOQMY 


his special AEA (Advanced 

Electronic Applications, Inc.) 
edition has been adapted from a book of 
the same title by Jim Grubbs imprinted 
for Radio Shack. 


Digital Communications With 
Amateur Radio,is written as a very basic 
introduction to Amateur Radio and 
telephone line digital modes. Itis not just 
an introduction to packet radio. The 
book is geared towards both the com- 
puter hobbyist looking for something 
new to do with his computer and the 
Amateur Radio operator wanting a basic 
understanding of digital modes and tech- 
niques. 


The book opens with brief survey of 
Amateur Radio and computer com- 
munications. But with phrases such as 
“What may come as a surprise to you is 
that data is also flowing right by your 
head now as you read this words. 
Electromagnetic waves of all kinds are 
carrying computer information to points 
around the world with using wires to do 
so!” the book sets its tone at the very 
basic level. The book then moves into a 


basic overview of digital theory, cover- — 


ing terms as: serial and parallel lines, half 
and full duplex, asynchronous and 
synchronous communication, and 
modems. 


And that completes the introduction. 
From there we move to Amateur digital 
modes. Every wondered how a mechani- 
cal Baudot teletypewriter worked? 
There is a full page drawing if you are 
interested. Even a section on punched 
paper tape is included, FSK and PSK are 
covered and some basic computer 
hardware connections for radios are 
shown such as AEA Computer Patch and 
Comm 64. Moving into the world of 
packet radio we look at the OSI seven 
layer model, AX.25 and CSMA. A big 
jump for a book that a few chapters ago 
was wondering if we know “Electromag- 


MARS and the Digital World 


Allan Chapman, WOMEO 


Mee Affiliate Radio System 
comprises mostly volunteer 
hams, operating at a home QTH. Active 
duty service members are in some key 
positions at gateway stations, but many 
are closing. 


MARS operates on military frequen- 
cies outside the ham bands, and com- 
petition is fierce within and between 
services, other government agencies, in- 
dustry, and the rest of the world! A 
secondary support and morale mission 
does not have a lot of leverage. So, 
MARS is very gradually learning ef- 
ficiency and spectrum economy 
through more modern techniques. 


Here in Northern California we find 
that NTS (amateur) traffic is refiled into, 
or taken from, MARS by members using 
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packet, RTTY, SSB, FM, telephone, 
sometimes even U.S. Postal “Service.” 
The one biggest hassle right now is 
determining where overseas we can ad- 
dress a message. It changes nearly daily 
in some way; it varies between the 3 
services; requirements seem to be tough, 
but enforced locally only sporadically. 


To enter an ordinary Traffic message 
via packet (or any other medium), the 
ham sends it to either a known member, 
or uses the NTS routing for the destina- 
tion. Format is not as important as con- 
tent, since the MARS member must 
massage the data into correct format. Fol- 
low exactly the most stringent set of 
MARS rules, knowing that a guy named 
Murphy is downstream just looking for 
flaws as a reason to K)ill your message 
because that reduces his backlog. Steve 
Harding KA6ETB has incorporated 


netic waves of all kinds are carrying com- 
puter information.” 


A history of TNCs are covered, then 
the offerings from AEA are shown. On 
the air operating procedures are covered, 
but using AEA software.. Some of the 
basic TNC parameters are given review 
also. Networking is next, with such 
topics as channel congestion, hidden 
nodes, LANs and WANs, and the 
gateway concept. (The BBSs in NCPA 
follow the gateway concept.) Software 
and hardware to make your PC act asa 
TNC is touched briefly. 


A chapter on packet radio accessories 
follows. Offerings from companies 
other then AEA and Radio Shack are 
mentioned. But as the copyright of this 
book is 3 years old, there are many new 
products out on the market today. Packet 
organizations are covered, but sadly no 
listing of NCPA. 


The book then closes with a brief 
chapter on the packet satellite operation. 
Again, here the book shows its age. 


As I stated at the beginning, this book 
tries to serve the need of both the 
Amateur Radio operator and the com- 
puter hobbyist. There is not enough in- 
formation here for the computer hobbyist 
to get on the air, and not enough informa- 
tion to completely help the Amateur 
Radio operator who is on the air. Trying 
to serve the needs of both, it 
does neither. 


those rules into this file on NCPA BBSs: 
NTS/mars.NTS. 

Those who want infoon MARS mem- 
bership should +NOT+ try to use forms 
from a friend who happens to have one. 
They are usually obsolete and will 
bounce. Instead, write to: 


Chief Army MARS 
USAISC/AS-OPS-OA 
Ft. Huachuca, AZ 85613-5000 


Chief Navy-Marine Corps MARS 
Navy Comms Unit 
Washington, DC 20390-5161 


Chief USAF MARS 
Hq AFCC/DOYX(MARS) 
Scott AFB Il 62225-6001 
2, 

W6MEO @ WD6CMU 

aka afa6jv 


EOF 
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The Downlink 


Young Folks and Ham Radio 


Travis Wise, KB8FOU 


(Editor's note: Travis is an active 15 
year old ham who is working hard to 
encourage other young people to check 
out Ham Radio, He serves on the Board 
of Directors for the West Valley Amateur 
Radio Association, and distributes many 
bulletins via the packet BBSs regarding 
youth involvement with ham radio. 
Travis continues writing from a perspec- 
tive that all of us over the age of thirty 
need to recall — even if it is ancient 
history to us. Could this view be insight- 
ful? I hope so.) 


\ A Je all know that young folks are 
important to the survival of 


Amateur radio, and that fact has been 
brought out with the arrival of no code. 
Since the FCC quickly dropped no code 
on our doorstep, hundreds of hams 
rushed to their packet terminals and sent 
out their opinions about no code to 
ALLUS. Most of the bulletins which 
were pro-no code mentioned something 
about the importance of youth in our 
hobby. Whether you are pro-no code or 
not, we can all be agreed on one thing: 
today’s young hams are the future of ham 
radio. 


The saying: “The average age of a 
ham radio operator is dead” is no longer 
true! The average age is, in fact, 51.19 
(as of 1988). Richard Hoffbeck, 


NOLOX, has prepared a two page report 
which breaks down the ages and dispels 
some myths about ham radio’s age prob- 
lem. Just how bad of a problem is it? 
Well, Richard thinks that in 20 years, it 
will be a “troublesome problem.” In 
1988, there were about 480,000 hams in 
America. Of those, 3%, or 10,345 were 
under the age of 20. Three out of one- 
hundred! Think about your local ham 
club. Are there three young hams per 
one-hundred? Probably. Keeping in 
mind that about half of all hams are ac- 
tive, there are about 5,000 active young 
hams in America. While these figures 
are from 1988, they are probably still 
accurate. 


Richard also reports that it is false to 
assume that since the number of hams has 
been growing at a faster rate than the 
population as a whole, ham radio is at no 
risk of becoming a dying hobby. It is 
faulty to assume that society as a whole 
has remained at the same level of tech- 
nology. 


How does all of this fall in with pack- 
et? Well, you have probably seen a few 
bulletins go by from teachers who use 
amateur radio in their classrooms, and 
are looking for other hams to exchange 
messages with their students. Ihave a list 
of about fifteen of these schools. There 
are also about thirty young hams on pack- 
et nationwide who I have come in contact 


PPRS is alive and well... . 


Northern California’s oldest packet radio user groupis still 
meeting every month. The Pacific Packet Radio Society 
(PPRS) meets on the first Tuesday of each month at the 
Ampex Cafeteria, 411 Broadway, Redwood City. The 
meetings start at 7:30 p.m. and are over by about 9:30. 


Over the years, meetings have had as many as a hundred 
people. The October, 1989, earthquake kept us from meet- 
ing in the cafeteria for a few months. Since then, atten- 
dance has dwindled to one to three dozen people. Please 
join us for a meeting this year. This can bea great place to 
get together and get questions answered. 


The Ampex Cafeteria is located in the same building as the 
Ampex Museum, facing the reflecting pool. This is just 
West of 101 and about a mile South of Woodside Blvd. 


with in the last year. I am hoping that 
with the codeless Technician license that 
these numbers will grow, and every club 
will have a ham radio class, and every 
school will have a ham radio club...some- 
day. 

When I first started my campaign to 
find other young hams in packet radio, I 
received one message from a grouch who 
didn’t think packet radio was the place 
for a newsletter/bulletin regarding pack- 
et. He has been proved wrong by the tons 
(or shail I say, bytes?) of messages I have 
received in overwhelming support of 
“The Packet Racket.” I now have a list 
of about twenty young hams who I cor- 
respond with often, some of which have 
their Advanced license! 


Now that The Packet Racket is in it’s 
10th edition, I have received only a few 
comments from the HF gateway Sysops 
asking me to reduce the size of the bul- 
letin to below 3KB (the first 3 editions 
were over 5KB). I have tried my best to 
do that, and each message is now under 
2KB. 


So, while many folks are sending 
5KB+ files all over the country about the 
War and other such topics, I’m doing my 
best to help the HF gateways be as effi- 
cient as possible. 


I think packet is the future of Ham 
radio, along with satellites, and maybe 
even moonbounce. I’m hoping that 
within a few years, all packet will be 
9600 baud, and HF packet stations can 
operate automatically just like VHF sta- 
tions, without the yearly “okay” by the 
FCC (that is ridiculous). It’s obvious 
now that, at least in the Bay Area, we are 
going to have to increase the number of 
packet frequencies in the near future, as 
well as continue to encourage packet ac- 
tivity as well as the TNC has. 


So, while we wait for our numbers to 
swell, someone to totally revamp the 
packet system so that it can handle in- 
finite quantities of messages, and devise 
a forwarding system such that the 
propagation on HF won’t make a dif- 
ference, we can sit back, and read the 
mail, and enjoy packet radio, and the 
great amount technology that exists in 
the small box next to our computers. 


73 de Travis, KB8FOU @ N6ITU. 


el 


Spring, 1991 


Page 9 


Putting TCP/IP On The Air 


Larry Kenney, WB9LOZ 
NCPA Education Coordinator 


lhere have been several articles 
written about various aspects of 
TCP/IP here in “Downlink,” but one has 
been missing. In issue number 1, 
Dewayne, WA8DZP, gave you an over- 
view and a detailed explanation of the 
protocols used. In issue 2, Doug, 
N6OYU, explained the TCP/IP Callsign 
Server and in the last issue there were 
three articles relating to TCP/IP: details 
from Weo, WN6I, on his San Jose 
Switch, a book review from Pat, 
N6QMY, on “Internetworking with 
TCP/IP,” and a new column on TCP/IP 
from Dewayne. However, there has been 
nothing written on where to find the 
software or how to go about getting a 
station on the air. Seeing that I recently 
set up my station on TCP/IP and the 
information is fresh in my mind, so I’m 
going to tackle that in this article. 
Getting your station set up will require 
some time and effort on your part. You 
can’t just puta disk in your computer and 
go on the air. You have to get an IP 
address, set up specific directories, get 
some needed files, and make up a few 
necessary files for your operation. You 
also need a TNC that operates in KISS 
mode. Most now have the KISS com- 
mand available, but check your TNC 
operating manual before you start any- 
thing else to ensure that the KISS com- 
mand is available in your TNC. Also 
while you have the manual out, learn how 
to use the KISS command; it works dif- 
ferently from most commands you’re 
familiar with. 


The Software 


The first thing you need, of course, is 
the software. The KA9Q Internet Pack- 
age, commonly called NET, is the most 
common program in use today. There 
are versions available for the PC and 
clones, the Macintosh, Amiga and Unix. 
Where do you get it? The easiest source 
is a local ham that has a copy of the 
version you need. Put a message on your 
local BBS to see if there is anyone in your 
area that is already on TCP/IP. Not only 
will you be able to get the software from 
him, but you'll have someone to ask 
questions of if you have problems. 


The Tucson Amateur Packet Radio 
Association (TAPR) has the version for 


the PC and clones available for $4.00. 
This is a special “Plug and Play” set of 
disks with sample files included along 
with instructions for setting up your hard 
drive with the proper directories. You 
can write to them at TAPR, PO Box 
12925, Tucson, AZ 85732, or call them 
at (602) 749-9479. 


If you have a telephone modem, there 
are several sources available to you. You 
can download the package from some of 
the ham related telephone BBSs, Here in 
Northern Califomia you can call Dennis 
Humphrey WA6RDH’s BBS in Dixon at 
(916) 678-1535. The software is also 
available on Howard Leadmon 
WB3FFV’s BBS in Maryland at (301)- 
335-0858, or Gary Sanders N8EMR’s 
BBS in Ohio at (614)-457-4227. All ac- 
cept 1200/2400, 8 bits, no parity, 1 stop 
bit. The software is also available from 
Compuserve in the Hamnet section. If 
you have a DRSI plug-in TNC, you al- 
ready have what you need. A copy of the 
TCP/IP software that has already been 
configured for use with the DRSI card 
was included with it. 


IP Address 


In addition to the software, you also 
need to obtain an IP address. This is a 
series of numbers that will uniquely iden- 
tify your station on the air. To get an 
address assigned to you, contact the IP 
address coordinator in your area. In the 
Bay Area it’s Douglas Thom, N6OYU @ 
K3MC, and in the Sacramento area it’s 
Bob Meyer, KORTV @ WA6NWE. In 
other areas, ask around to find out who 
the local IP address coordinator is, or 
contact Brian Kantor, WB6CYT, the na- 
tional IP address coordinator, at 7108 
Werner Street, San Diego, CA 92122. 


Send the following information with 
your request: 


«Your first name, last name and 
callsign. 


¢Your full mailing address. 


«The city where your TCP/IP station 
is going to be located. 


«Whether or not it’s a home or work 
location. 


«The callsign of your home BBS. 


*Your Internet address, if you have 
one. 


Files Needed 


Acopy of the HOSTS.NET file is also 
required. It’s available for downloading 
on many of the packet BBSs in Northern 
California or from the WN6I-7 San Jose 
Switch on 145.75 MHz. If using your 
local packet BBS, check for a TCP/IP 
directory using the W command. If you 
can’t locate the file, ask your local sysop 
for assistance. The file is fairly lengthy, 
so plan on spending a little time 
downloading it. The HOSTS.NET file is 
used by the NET software to look up the 
IP address for each station you wish to 
contact, so you’! need it before you go 
on the air with your TCP/IP station. 


If you’re using the PC/clone version 
of NET, I strongly suggest that you also 
get acopy of the file BEGIN.DOC, writ- 
ten by Gary Ford, N6GF. It explains 
what you need to do to set up your station 
in clear, easy to understand terminology 
and then goes into details on all of the 
commands used with the NET program. 
There is documentation that comes with 
the software, but I found it to be difficult 
to understand in many places. It also 
isn’t as complete as Gary’s and the 
descriptions of some of the functions are 
missing. Gary’s documentation takes all 
of the guess work out of the process. 


There are two other files you'll also 
find very helpful once you’re up and 
running. One is called FINGER.DOC, 
describing the user identification ap- 
plication, and the other is BM.DOC, the 
“BM User Manual” by Dave Trulli, 
NN2Z. 


All four files, HOSTS.NET, 
BEGIN.DOC, FINGER.DOC and 
BM.DOC, are available in the TCP/IP 
directory of the W6PW-3 BBS on 144.99 
MHz in San Francisco. If you can’t con- 
nect to that BBS or find a copy of the files 
locally, send me a formatted disk with 
return postage and I'll be glad to make a 
copy of the files for you. Ican copy to 3 
1/2" 1.44M or 5 1/4" 1.2M or 360K disks. 
My address is 4145 21st Street, San Fran- 
cisco, CA 94114. 


Hard Disk Setup 


Before installing the program on your 
computer, special directories need to be 
established on your hard drive for use by 
the TCP/IP program. Under the root 


Continued on page 12 
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The Downlink 


TCP/IP Column 


Dewayne Hendricks, WA8SDZP 
i my last column I discussed some 
of the background and what I called 
the “why” of TCP/IP. I hope that you 
found the information there useful. 
Since no one has sent me any questions 
about the last column, I can only assume 
that everyone out there understood it and 
would like me to move ahead. In this 
column I had promised to discuss the 
“how” of TCP/IP and how you could get 
Started with the available implementa- 
tions for the type of personal computer 
which you have. However, I worked out 
an arrangement with Larry Kenney 
WB9LOZ, who writes the excellent “In- 
troduction to Packet Radio” series to in- 
stead write a “how to” article for this 
issue. Larry just brought up TCP/IP at 
his own station so we felt that he would 
be in a much better "state of mind" then 
I to write about what it takes to get a 
TCP/IP station on the air. Larry’s article 
in on how to get TCP/IP up on an IBM 
PC or compatible. If there is enough 
interest on how to do the same with other 
platforms (Macintosh, Amiga, UNIX, 
etc.) then we will do a “how to” column 
for those platforms also. 


In past issues of Downlink, I have 
written about the lower levels of the 
TCP/IP protocol suite. I have covered 
briefly what are called the “Transport” 
(TCP and IP), and “Internetwork” (IP 
and ICMP) protocol levels. In this 
column I would like to discuss some of 
the highest level protocols of the TCP/IP 
protocol suite. These protocols of the 
TCP/IP protocol stack are called ‘“ap- 
plication protocols.” They communicate 
with applications on other internet hosts 
and are the user-visible interface to the 
TCP/IP protocol suite. 


Characteristics of Applications 


All of the higher level protocols have 
some principles in common: 


1. They can be user-made applica- 
tions or applications which are stand- 
ardized and shipped with a TCP/IP 
product, such as NOS. As I’ve men- 
tioned in the past, the TCP/IP protocol 
suite includes such “standard” applica- 
tion protocols such as: 


* TELNET (TELetypewriter 
NETwork) for interactive access to 
remote internet hosts. 


¢ FTP (File Transfer Protocol) for 
high-speed disk-to-disk file trans- 
fers. 


- SMTP (Simple Mail Transfer 
Protocol) as an internet mailing sys- 
tem. 

These are the most widely imple- 
mented application protocols, but a lot of 
others exist. Each particular TCP/IP im- 
plementation will include a more or less 
restricted set of application protocols. 


2. They use either UDP or TCP as a 
transport mechanism. Remember that 
UDP is unreliable and offers no flow- 
control, so in this case, the application 
has to provide its own error recovery and 
flow-contrl routines. It is often easier to 
build applications on top of TCP, a reli- 
able, connection-oriented protocol. 
Most applications protocols use TCP, but 
there are applications built on UDP for 
special reasons, such as higher perfor- 
mance available through its use of a con- 
nectionless architecture. An example of 
such an application is the Network File 
System (NFS) protocol which was 
developed by SUN Microsystems and 
allows for the remote access of file sys- 
tems over the Internet. 


3. Most of them use the server-client 
model of interaction. 


Server-Client Model 


Let me elaborate a bit on this notion 
of server-client (yes, not client-server!). 
TCP is a peer-to-peer, connection- 
oriented protocol. There are no 
master/slave relationships allowed in the 
protocol definition. Most applications 
you can think of though use a serv- 
er/client model for communications. A 
“server” is an application that offers a 
service to internet users; a “client” is a 
“requestor” of a service. An application 
consists of both a server and a client part, 
which can run on the same or on different 
systems. Users usually invoke the client 
part of the application, which builds a 
“request” for a particular service and 
sends it to the server part of the applica- 
tion using TCP/IP as a transport vehicle. 
The server is a program that receives a 
request, performs the required service 
and sends back the results in a “reply.” 
A server can usually deal with multiple 
requests (multiple clients) at the same 
time. Some servers wait for requests at a 


“well-known port” so that their clients 
know to which IP socket they must direct 
their requests. The client uses an ar- 
bitrary port for its communication. 
Clients that wish to communicate with a 
server that does not use a well-known 
port must have another mechanism for 
learning to which port they must address 
their requests. This mechanism might 
employ a registration service such as 
“Portmap,” which uses a well-known 
port. NOS as it stands does not imple- 
ment such a service and applications 
which are currently implemented all use 
well-known ports. Let’s go more into 
detail of one of the more common ap- 
plication protocols, TELNET. 


TELNET 


The TELNET protocol provides a 
standardized interface, through which a 
program on one host (the TELNET 
client) may access the resources of 
another host (the TELNET server) as 
thought the client were a local terminal 
connected to the server. For example, 
the TELNET command from an IBM PC 
running a TCP/IP implementation under 
DOS may be used to login to a UNIX 
host, making the PC look like a UNIX 
user’s terminal to the host. 


The TELNET protocol is based on 
three ideas: first, the concept of a “Net- 
work Virtual Terminal (NVT);” second, 
the principle of negotiated options; and 
third, a symmetric view of terminal and 
processes. An NVT is an imaginary 
device, providing the necessary basic 
structure of a standard terminal. Each 
host maps it’s own terminal charac- 
teristics to this NVT, and assumes that 
every other will do the same. The prin- 
ciple of negotiated options is used by the 
TELNET protocol, because many hosts 
wish to provide additional services, 
beyond those available with the NVT. 
Various options may be negotiated. 
Server and client use a set of conventions 
to establish the operational charac- 
teristics of their TELNET connection via 
the “DO, DON’T, WILL, WON’T” 
mechanism. To begin the negotiation, 
hosts have to verify their mutual under- 
standing, using a standard syntax. Then, 
after a minimum of understanding, they 
can experience sub-negotiation under a 
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directory (C:\on most systems) you need 
to make directories titled FINGER, 
PUBLIC and SPOOL, as shown in the 
diagram. Under the SPOOL directory 
you need to add four sub-directories 
called FOLDER, MAIL, MQUEUE and 
RQUEUE. 


\ (root directory) 
| 


}—FINGER 
I—PUBLIC 
L-SPOOL 
| 
FOLDER 
+-MAIL 
I—MQUEUE 
I—RQUEUE 


The FINGER directory is used to 
identify users of your TCP/IP station. 
The file FINGER.DOC explains the 
operation of the FINGER application and 
the files needed in this directory. The 
files are NOT needed to put your station 
on the air with TCP/IP. 


The PUBLIC directory, and any sub- 
directories you want to add to it, is the 
area accessible to users of your station, 
similar to the files area of your packet 
BBS. You can develop this area after 
you get on the air and become familiar 
with TCP/IP operation. 

The SPOOL directory is used for your 
automatic station log. 


The FOLDER sub-directory is where 
files are stored when you save any mes- 
sages as files. 


The MAIL sub-directory is where in- 
coming messages are stored. 


The MQUEUE sub-directory is for 
outgoing messages. 

The RQUEUE sub-directory is for 
messages that have been received for 
processing by a user-defined mail rout- 
ing program. (I have no idea what this is 
about Nothing has ever ended up in 
RQUEUE on my station.) 


Files Used 


Next, you need to make up a couple 
of files used by the NET program. The 
documentation that comes with the pro- 
gram gives you examples of what you 
need to enter in these files. 

The first file is AUTOEXEC.NET, a 
series of commands and information 
needed by the program. (This file should 


not be confused with your 
AUTOEXEC.BAT file.) When the NET 
program first starts up it reads this file 
and executes the commands contained in 
it, setting up the initial configuration for 
your system. It sets the hosmame, AX.25 
parameters, interfaces and other vari- 
ables necessary for your particular sta- 
tion. Make sure that you have the correct 
entry for the COM port you’re going to 
use for your TNC. Most enter “‘ax0” for 
COM1. 


The next file you need to write is 
FIPUSERS. It establishes the access 
levels for users of your station. Be very 
careful when writing the information for 
this file or outsiders will be able to get 
into your private personal files. It’s not 
advisable to give permission above level 
3, as outlined in the documentation. 


Both of these files, 
AUTOEXEC.NET and FTPUSERS, the 
file HOSTS.NET, and the files 
NET.EXE and BM RC that come with 
the software package, are placed in the 
ROUTE directory. 


Putting It all on the air 


When you have all of the files saved 
to the proper directories you should be 
ready to go on the air. Set up your radio 
for simplex operation. The TCP/IP fre- 
quency in the Bay Area is 145.75 MHz, 
and in Sacramento it’s 144.93 MHz. If 
you live in another area, ask around Jo- 
cally for the frequency used. 


Using your normal computer terminal 
program, check your TNC to computer 
baud rate and make sure that it matches 
the baud rate you entered in 
AUTOEXEC.NET. Set DWait to 0, Per- 
sistence ON, and SLOTtime to 160 ms., 
then turn KISS ON. As explained ear- 
lier, the operation of KISS mode varies 
from normal command usage, and even 
varies from TNC to TNC, so read your 
TNC manual for details on the KISS 
command. With the AEA PK-232 you 
will also have to turn HOST ON. Be 
careful that your terminal program 
doesn’t take you out of KISS mode when 
you exit it. Some do! I use Pro-Comm 
and it works fine. 

When the radio and TNC are ready, 
enter NET at the DOS prompt, cross your 
fingers and see what happens. You 
should get the prompt “NET”. My sta- 


tion came up on the first try! [hope yours 
does also. 


To monitor the frequency, you will 
need to enter “trace cmdmode” <CR> 
followed by “trace ax0 111” <CR> (ax0 
is assuming COM1). These two com- 
mands can be added to 
AUTOEXEC.NET if you want automat- 
ic monitoring. That way you don’t have 
to type it in each time you come on line. 


The first thing you'll probably want to 
do is to see if eveything is working okay. 
The easiest check is to make an AX.25 
connection with another station that you 
know is on frequency. Enter “connect 
ax0 <callsign>” <CR>, where 
<callsign> is the station you want to con- 
nect to. For example, to connect to 
WB9LOZ you would enter: c ax0 
wb9loz. If everything is working as it 
should you will soon receive “conn pend- 
ing” followed by “connected.” After 
spending all of your time and effort set- 
ting up your TCP/IP program, you have 
now completed a normal packet AX.25 
keyboard to keyboard contact! To dis- 
connect, use the F10 key to escape back 
to the NET prompt, and then enter “dis- 
connect” or “d’”. (Most of the commands 
can be abbreviated.) 


If your station is working, congratula- 
tions! You now have the world of 
TCP/IP awaiting you. Using the 
documentation provided with the 
software, or better yet, BEGIN.DOC, 
you can now start checking out the 
various commands. The TELNET and 
FTP commands are the two most fre- 
quently used for contacting other TCP/IP 
stations, but I also find that using 
FINGER is fun. 


Make sure you check the STATUS 
and TCP STATUS before going off line 
to make sure all sessions have been com- 
pleted. You’ll be surprised quite fre- 
quently to find other stations sending you 
messages, uploading or downloading 
files, and you didn’t even know they 
were connected. 


There were a couple of things that I 
didn’t understand when I first got on the 
air with TCP/IP, so I'll pass those on to 
you now. To enter messages or to read 
messages, you have to escape NET and 
then enter the BM Mailer from the DOS 
prompt. To escape, you enter an ex- 
clamation point (!) at the NET prompt, 
then enter BM at the DOS prompt. When 
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“free” syntax. Because of the symmetry 
of the terminals or processes, every host 
has the opportunity to negotiate its op- 
tions. 

The NVT has a printer (or display) 
and a keyboard. The keyboard produces 
outgoing data which is sent over the 
TELNET connection. The display repre- 
sents the incoming data. To help sustain 
a high level of performance on the net- 
work, echoes to the display are not ex- 
pected to traverse the network. The 
option for enabling a remote echo mode 
exists, but no host is required to imple- 
ment it. The data representation used is 
a7 bit ASCII code in a 8 bit field, except 
as modified. The NVT can be viewed as 
a half-duplex device operating in a line- 
buffered mode. This is the default option 
set in use before negotiation begins with 
the host. 


The communication between the 
client and server is handled with internal 
commands, which are not accessible by 
users. All internal TELNET commands 
consist of two or three byte sequences, 
depending upon the command type. The 
Interpret As Command (IAC) character 
is followed by a command code. If this 
command deals with option negotiation: 
the command will have a third byte to 
show the code for the option referenced. 
I will not cover the various commands 


here, but instead refer you to the docu- 
ments which specify the various TEL- 
NET options, the RFC’s (Request for 
Comments). The TELNET protocol is 
covered by quite a number of RFCs, too 
numerous to mention here. For starters, 
try RFC 854, which is the basic protocol 
specification. Next, you should give a 
look to RFC’s 856, 857, 885 and 930. 


RFC’s 

The Internet protocol suite is still 
evolving through the mechanism of 
RFC’s. New protocols (mostly applica- 
tion protocols) are being designed and 
implemented by researchers, and are 
brought to the attention of the Internet 
community in the form of an RFC. Some 
of them are so useful that they become a 
“recommended” protocol, that is, all fu- 
ture implementations of TCP/IP are 
recommended to implement this par- 
ticular function or protocol. Other RFCs 
are purely research ideas and not ready 
for implementation. Therefore, a status 
attribute is given to each RFC, indicating 
the stage of evolution and acceptance of 
this particular idea for the TCP/IP 
protocol suite. 

All RFCs are available publicly, both 
in printed form and as Internet mail from 
the Network Information Center (NIC). 
They can be obtained in printed form 
from: 
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you're finished with the messages, you 
enter “q” to get back to the DOS prompt 
and then enter “exit” to resume operation 
of NET. To get out of NET completely, 
you enter “exit” at the NET prompt. 
When you have things set up as you 
like them, send me a message and let me 
know you're on the air 


(wb9loz%wb9loz@wé6rfn). If you’re in 


Tidbits 
Check out page 152 of the 
April, 1991 issue of Scientific 


American. There is a short half 
page article on the new no-code 
Technician. 


the Bay Area we can meet for fun and 
games on Marc’s system. Enter: “telnet 
noe.kg6kf 6715”, and beware of the 
Wizard! 

Anew TCP/IP program called NOS 
is now in development and several sta- 
tions here in Northem California are al- 
ready using it quite successfully. Once 
you get on the air with NET, you might 
want to upgrade to NOS in time. NOS is 
available for the PC/clones by sending 
two 5 1/4" disks or one 3 1/2" 720kb 
diskette to W. E. Moerner, 1003 Belder 
Drive, San Jose, CA 95120-3302 in a 
mailer with return postage. NOS for the 
Mac is available from Doug Thom, 
N6OYU, (408) 253-1306, 1405 
Graywood Drive, San Jose, CA 95129- 
4778. Amiga NOS is available on Com- 


DDN Network Information Center 
SRI International 

333 Ravenswood Ave. 

Menlo Park, CA 94025 


The electronic version are available 
on a number of places on and off the 
Internet. If you have any trouble getting 
to one you want, contact me at my 
electronic addresses below and I will try 
to give you a hand. 


Wrapup 

The big points I wanted to make this 
month with you was the importance of 
the application protocols and there role 
in the whole TCP/IP suite of protocols. 
If you are interested in any specific ap- 
plication protocol, such as FTP and even 
NES, get a copy of the appropriate RFC 
and give itaread. The only way I think 
that you’ll really become familiar with 
the TCP/IP suite of protocols is to start 
out ona process of discovery by charting 
your way through the RFCs. Armed with 
the RFCs and a copy of the source code 
for the KA9Q NOS, you should be all 
ready to embark on your adventure. 
Good hunting!! 

In my next column, I will talk about 
the future of NOS in the amateur packet 
radio world. Till then, I can be reached 
at 75210.10@compuserve.com on the 
Internet or WA8DZP @ K3MC.#NOR- 
CAL.CA.US on the PBBS net- 
work. Be seeing you! EOF] 
puserve in Hamnet Library #9 or by con- 
tacting Chris, WA2KDL @ 
K6VE.#SOCA.CA. UNIX and other 
operating systems can get the c code for 
NOS from various internet ftp sites. 
Contact marc@noe.kg6kf for further in- 
formation (KG6KF @ K3MC on the 
BBS circuit). 

Sites that are already on NET can 
get many flavors of NOS from W6RFN 
by anonymous FTP in the /public/nos- 
code directory. He has built up an exten- 
sive help file directory on W6RFN to 
assist the beginner on NOS. N6PAW, 
KG6KF, and W6REN are constantly re- 
compiling the source code to make it 
adapt to their needs and will be glad to 
share their experiences. 


Enjoy your TCP/IP experiences! 
73, Larry, WB9LOZ 
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Marcello Soliven, KJ6QA 


(Editor's note: Marcello continues 
reporting from the hinterlands of 
Florida. To those of us with kids out here 
on the Left Coast, the thoughts of Disney 
World on the Right Coast don't sound 
like an “exile”, but then again it would be 
an exile without hot tubs and sushi.) 


reetings again from the tropics. 

So much has happened since the 
last issue of DOWNLINK.... whew!! I 
have to admit that some of my radio time 
has been replaced by one-way QSO par- 
ties with Peter Amedt. 

Realizing the need to thwart the woes 
of a potential news junky, I had to just 
“say no” to the news and put my energies 
toward rehabilitation. I cast the tv remote 
aside and ran for sanctuary — the ham 
shack. As I entered I was greeted with the 
warm, amber glow of three packet 
monitoring systems. While monitoring 1 
hf and 2 vhf channels, my electronic 
scribes of packetdom cataloged with 
great accuracy the data transfers, bbs 
beacons, and other digital events of most 
recent history. Well, maybe it wasn’t 
quite that dramatic, but the multiple 


monitoring systems spawned a solution 
to a problem posed by a club event coor- 
dinator. 


The Problem 


Amateur radio and amateur radio as- 
sisted civic events are often comparative- 
ly large. Events may be divided into 
smaller areas such as pavilions, arenas, 
fields, blocks, or even different cities or 
towns, thus making logistics interesting 
at best. Information from a central or 
command point will need to be dissemi- 
nated that contains data pertaining to 
event coordination, safety an- 
nouncements, participant/spectator bul- 
letins, etc. Voice radio is adequate for 
security or general purposes but falls 
short when larger volumes of data have 
to be moved to specific places quickly. 
Packet radio is a natural solution and the 
TAPR standard helps simplify the 
software task. The following ideas are 
offered as enhancements that can spice 
up an event and perhaps its efficiency. 


A Solution 


1. Use packet linked remote dis- 
plays/monitors each consisting of... 


- A TNC with standard TAPR com- 
mand set. 


¢ Areceiver (scanner is usually ok). 


* A terminal device, Vic-20, they’re 
common, easy to use, and cheap. 
The Vic-20 utilizes bigger charac- 
ters which are easier to read, espe- 
_Cially from the back of small crowds. 


*  Acolor display, 19 inch or larger if 
possible. 


2. The TNC can be set to a specific 
callsign or address name and decode data 
sent specifically to that device. 

3. Several monitoring units can have 
the same address, thus allowing group 
related distribution of a data type. 

4. Another approach to decoding 
specific data would be to set the budlist 
so as to exclude impertinent data. 

5. Since the Vic-20 also provides 
NTSC video, another suggestion may be 
to use an ATV transmitter for additional 
distribution. In this case station ID 
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California’s Digital Public Information System 


From Disaster Research, 
January 3, 1991 
he California Office of Emergen- 
cy Services (OES) in partnership 
with California broadcasters is testing a 
new approach to emergency public infor- 
mation delivery. 


The “Emergency Digital Information 
System” (EDIS) links digital radio trans- 
mitters to emergency-managementagen- 
cy computers. The result is an official 
“news wire” which lets local, state, and 
federal agencies transmit emergency 
messages directly to printers in radio and 
TV stations, wire services, and govern- 
ment operating centers. 


Broadcasters and organizations for 
the hearing-impaired have embraced 
EDIS, calling it an important supplement 
to the Emergency Broadcast System 
(EBS). A bill signed into law by Gover- 


nor George Deukmejian this fall directed 
California OES to investigate possible 
statewide implementation. The experi- 
ment has drawn nationwide attention in 
the broadcast industry trade press and 
sparked the interest of FEMA and FCC 
officials in Washington. 


EDIS receivers can be assembled for 
less that $500 (including printer) using 
readily-available “scanner” radio 
receivers and a ham “packet radio” 
modems. The digital output of the 
receiver can be routed to a printer, or 
directly into a newsroom computer sys- 
tem or TV graphics generator. 


Authorized officials can originate 
emergency news releases over EDIS 
from terminals on several existing 
government computer networks, The 
largest of these is the California Law 
Enforcement Telecommunications Sys- 


tem (CLETS) which supports over 
14,000 terminals in law enforcement and 
dispatch centers statewide. EDIS is also 
linked to the computers of the National 
Weather Service and the U.S. Geological 
Survey. 

The pilot project has been in operation 
serving the San Francisco Bay and 
Sacramento Valley areas since June. 
California OES hopes to extend EDIS 
service into Southem Califomia during 
1991, 


For more information write or e-mail: 


Art Botterell 

EDIS Project Coordinator 

Calif. Office of Emergency Services 
360 Civic Drive, Suite 1 

Pleasant Hill, CA 94523 

Internet: oes2!art@water.ca.gov 
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Strategy was to have redundancy through 
multiple independent satellites. 


More pictures: UoSAT OSCAR-15, 
which failed shortly after launch and 
hasn’t been heard from since. The 
Microsat/UoSAT deployment 
mechanism: a spring, compressed with a 
bolt. The huge crowd of quality control 
people it takes to supervise the operation 
of tightening four bolts to mount a 
Microsat to the ASAP. Cleanroom 
equipment: just home PC’s, and donated 
gear from Kenwood, Icom, MFJ, and 
TAPR. NK6K attaching the umbilical 
cord to a Microsat, for charging and 
monitoring on the ASAP. A spider found 
in the cleanroom. SPOT-2, the primary 
payload. SPOT-2 and the Microsats 
mounted for launch - boy is SPOT-2 big 
compared to the Microsats! 


The pacsat mission was written up in 
an interview published in the May 1984 
issue of Byte. The original plan was a 
user interface similar to the familiar 
WORLI-style BBS software. Later it was 
realized that an interface that permitted 
and encouraged off-line typing and auto- 
matic forwarding would be better; 
humans type too slowly. With a satellite 
audible to large areas simultaneously, it 
makes sense to implement a broadcast 
protocol that permits listeners to 
reconstruct transmitted files. This 
protocol is currently in use for AMSAT 
News Service bulletins, Keplerian ele- 
ment sets, and so forth. 


For non-broadcast messages, the goal 
was automatic store-and-forward opera- 
tion. But it wouldn’t do to put the routing 
intelligence in the spacecraft— 
spacecraft software is hard to write, and 
forwarding schemes change all the time. 
So the satellite acts as a file server. The 
satellite software requires a special 
header on each file, which contains a 
description of the file’s contents. One 
field of the file header contains a free- 
form routing designator. The BBS 
software can use the routing scheme du 
jour to decide which files to download 
and forward. 


Question: What equipment is needed 
to work the Microsats? Answer: 70cm 
SSB receiver, 2m FM transmitter, PSK 
modem. PSK was chosen for reasons of 
efficiency. Software for ground station 
use is available via CompuServe, TAPR, 
and others. The spacecraft can also be 
used as a simple digipeater for realtime 
QSOs. 


Question: What is the life expectancy 
of the Microsats? Answer: The orbit 
lifetime is estimated at 107 years. Radia- 
tion damage may become a problem after 
3 to 7 years. The NiCd batteries have a 
relatively easy life, and are expected to 
last a long time. UOSAT OSCAR-11 
celebrated its 7th birthday yesterday with 
the same batteries, and is going strong. 

Question: Do you still plan to imple- 
ment the part of the broadcast protocol 
that permits ground stations to request 
fills for missed parts of a file? Answer: 
Yes. 
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should be included in each screen’s 
worth of data. 


6. With some programming 
creativity, use of the Vic-20 would also 
allow graphics and text together. Al- 
though it hasn’t been fully tested, it is 
possible that stop-frame animation may 
be generated and sent by the command 
point. One Vic-20 screen equals about 1 
packet at a paclen of 255. Through-put is 
perceived to be slow. 


7. To keep the system simple, use of 
just a receiver is suggested. In some 
cases, however, it may necessary to use 
a transceiver and take advantage of the 
full error detection scheme. Doing so, 


however, may preclude the use of the 
group address unless a cluster-like dis- 
semination program is used by the 
originating or command point. 


8. Use of a transceiver and digipeater 
capability at the remote site(s) will en- 
hance the physical range of the network. 
This has some intuitively obvious ad- 
vantages, 


9. Also as in #8, it will be possible for 
the command point to test the integrity of 
the entire monitoring system by “‘bounc- 
ing” a test packet to itself throughout the 
network. Note : It may be prudent to have 
at least one monitoring unit setup with a 
transceiver. This will allow communica- 


Question: What kind of NiCd bat- 
teries are used, and how are they 
managed? Answer: The charge level is 
managed by varying the transmitter 
power. The batteries are purchased com- 
mercially for $15 each, x-rayed, 
temperature tested, and grouped into sets 
matched for charge and discharge rates. 
From 200 batteries, 6 sets of 8 matched 
cells were obtained. Compare with the 
manufacturer-qualified price: $700 each. 


Lyle Johnson, WA7GXD, reading 
a letter from Tom Clark, W3IWI 
SAREX 


About 90% of the logs from 
WAASIR’s operation on the space shuttle 
have been processed. They amounted to 
400K of data plus 4 inches of paper list- 
ings. The QSL cards will be ready soon; 
the Goddard ARC will distribute them. 
238 “gold star” 2-way QSOs were logged 
by the GRiD laptop computer aboard the 
shuttle. 800 “silver star” QSLs will be 
awarded for stations heard by WA4SIR 
and awarded one of the 1700 QSO num- 
bers. The QSO rate averaged about 20 
per hour, peaking at 30 or 40 per hour. 
USA stations were greatly disadvantaged 
by interference, and by failure to run low 
modulation. 35 countries were logged, 
but no European stations were logged 
except a few SWL reports. It required 
over 200 pages of documentation to get 
authorization to carry the SAREX equip- 
ment on the flight. 


Continued on page 16 


tions to a system meeting the “unat- 
tended” criteria and avoid the “one way 
communications” rule problem. 


It’s been fun piecing this system 
together and trying various options. I’m 
sure that there are other possibilities of 
which I’ ll leave to your discovery. Drop 
a line to the address below and share 
ideas. while in my exile to Florida, Ihave 
become very active in scuba diving. In 
the next issue I hope to report on an 
underwater communications experiment 
that may be the first of its type. 


"til next time..... 
73, Marcello, KJ6QA (in exile) 
kj6gqa @ n4joa.#wpbfl.fl 
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Bob Nielsen, W6SWE, described 
a message from Jerry Crawford. 


A company called Hadron (spelling?) 
has a packet radio controller product, the 
PRC6064A, which is based on licensed 
TAPR technology. These devices are 
being used by special forces in Operation 
Desert Storm. 

Al Dennis, who has some connection 
to the Department of Defense, spoke up 
about DoD use of amateur packet equip- 
ment. They’ve been using it since we 
started. It is used for man-carried single- 
threaded narrowband links. The packet 
controllers work naturally with the lap- 
top computers and digital radios they al- 
ready have in the field. The 18th 
Airborne Corps has been building up ap- 
plications. Amateur-like packet is a de 
facto standard, because it’s cheap and 
give interoperability. 

Packet is used both point-to-point and 
in networks, For logistic information 
transmission, packet replaces Jeep shut- 
tles. Networking is coming, and inter- 
faces to the DDN. They want to extend 
the DDN right into the jeeps in the field. 


Question: Are you aware of tactical 
front-line use of amateur packet gear in 
Desert Storm? Answer: Yes! It is being 
used between camps in the desert. Then 
as the frontline troops advance, they out- 
run the logistics people - and use the 
packet thin-links to keep in touch. 

Question: Can you please give this 
talk to the FCC? Answer: Not sure we 
can get involved. We did push for 
reciprocal licensing with Persian Gulf 
states. Question: Regulatory issues are 
getting to be a problem. Pointing out the 
benefits of amateur radio may help keep 
the regulators from getting out of control. 
Answer: We don’tnormally deal with the 
FCC, but I'll do what I can. 


Question: Does the enemy have any 
trace of this kind of capability? Answer: 
No specifics, but note that TNC-2’s are 
available world-wide, and so are smart 
people. NK6K: Note that they aren’t 
using the TNC-2’s modem through a 
voice radio like we do. They connect 
digitally, through a Crypto unit. So the 
communications wouldn’t be easy to 
monitor. 


Question: How well does it perform? 
It’s not really optimized for this kind of 
work. Answer: It works well. Better than 


lhe NCPA has been selected 

by the ARRL to host the 10th 
ARRL Amateur Radio Computer 
Networking Conference which will 
take place on September 27-29, 1991 
in San Jose. Glenn Tenney, AAGER, 
will be this year’s conference chair- 
person. We are planning a variety of 
events throughout the conference 
weekend. Our plans are still being 
solidified, but we are planning: An 
afternoon of in-depth technical 
“tutorials” on Friday; a very special 
“theme” dinner Friday night; the 
CNC itself all day Saturday; a ban- 
quet dinner on Saturday night, com- 
plete with a special guest speaker; 
and something special on Sunday — 
even if you didn’t attend the rest of 
the CNC. 


More information on the con- 
ference will be available in the next 
issue of Downlink and other Ham 
magazines, Instead of waiting, send 
AAGER a SASE (this is a low-budget 


the other stuff they have. The amateur 
packet gear is the only error-correcting 
protocol they have that works on half- 
duplex radios. They even use it on UHF 
satellite links, which have just a few 
poor-quality channels available. NK6K: 
We have a cheap satellite design you 
might be interested in... Answer: We’re 
very interested, and we’ve had proposals 
for years, but haven’t gotten very far. 


Lyle Johnson, WA7GXD 
TAPR/AMSAT DSP Project 


TAPR and AMSAT undertook a joint 
project, spearheaded by N4HY and 
W3IWI. The idea was to handle the 
proliferation of different modems for use 
on HF, Microsats, RUDAK, and so on. 
By digitizing the analog signals, a high- 
speed processor can be used to simulate 
filter, PLLs, and other modem com- 
ponents. When the next new modem is 
needed, all that’s required is a new pro- 
gram for the DSP board — it’s only bits. 


The original efforts used the Dalanco- 
Spry Modem 10, a PC plug-in board 


conference) and we’ll send you com- 
plete information. Send your SASE 
to: 


Glenn Tenney 

10th ARRL CNC 
2111 Ensenada Way 
San Mateo, CA 94403 


We’ ve worked out a special room 
rate at the conference hotel, so start 
making your plans now. 


Past conferences have attracted 
over 150 participants from all over 
the U.S. and Canada, and more 
recently from other parts of the 
world. Conference speakers share 
the results of their most recent work 
at the leading edge of amateur packet 
radio. Proceedings of past conferen- 
ces are available for a nominal cost 
from ARRL HQ in Newington, CT. 
Please contact the ARRL for an 
authors’ packet. The deadline for 
papers is the beginning of August, 
and that will be here before you know 
It. 


based on the TMS32010 first-generation 
DSP processor from Texas Instruments. 
In 1988, the DSP project proposed a stan- 
dalone box with a TMS32015 (a slightly 
improved TMS32010), 4k words of 70ns 
memory, 8-bit analog I/O, provisions for 
a second DSP board in case extra horse- 
power is required, power supply, and 
V40-based controller board, all plugged 
into a back panel interface board. Boards 
were laid out, and some prototypes were 
built. Then the Microsat project got 
under way, and key project personnel 
were suddenly very busy. 


In January 1989, after the Microsat 
launch, the hardware team was freed up. 
The DSP project was revived at the 1990 
TAPR meeting. After a few months, a 
new design evolved: a PC plug-in board, 
based on a newer TMS320C25 proces- 
sor. By using a PC plug-in, the project 
can take advantage of cheap IBM PC 
development platforms, at least for the 
initial version. This is great except for 
Japan, where the popular PCs don’t have 
the IBM PC bus. The TMS320C25 is 
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much more capable than the TMS32010 
or TMS32015. It was too expensive 
when the project started, but now there is 
a version in the high $20’s range. 


The radio interface is still 8 bits wide. 
This gives about 40dB useful dynamic 
range. This is thought to be enough; the 
beta test will tell. Miscellaneous I/O like 
up/down tuning buttons are provided for. 
A sample clock phase-shifting circuit 
makes it possible to use lower sample 
rates. A watchdog timer is included. 
The DSP board has no ROM; it is booted 
from the PC. It takes up just 16 addres- 
ses from the PC’s I/O space, and no 
memory addresses at all. The PC can 
access DSP memory without disturbing 
the DSP processor, by inserting just 1 
wait state per access. An 8530 serial 
communications chip is included on the 
DSP board so it can handle the TNC 
functions easily. It should be especially 
easy to interface to the KA9Q TCP/IP 
software, since that software already sup- 
ports the 8530. 


A 6-layer beta test board was dis- 
played. It’s fully functional, with just a 
few white wires. The 4th ofa planned 10 
beta test boards is currently under con- 
struction. The beta test goal is to get 
some applications running to verify the 
applicability of the hardware. Then the 
production phase will begin. 

There was a discussion in the TAPR 
Board meeting about whether the DSP 
board should be sold as a kit or fully 
assembled, or something in between. 
Construction of the DSP board requires 
10 to 20 hours of careful work with a 
suitable temperature-controlled solder- 
ing iron. Beta test results will indicate if 
a kit is practical. A quick poll of the 
audience indicated that many people 
would be interested in a kit. Most of 
those liked the idea of having the solder- 
ing done for them, even if the soldered 
boards were untested. It has been 
claimed that assembled and tested boards 
would only cost $35 to $50 more. A poll 
showed that nobody would be interested 
in building the kit if the A&T version 
only cost $50 more. 


Question: When can I buy one? 
Answer: Depends on how the beta test 
goes. Definitely not by Dayton this year, 
but very confidently before Dayton °92. 

Question: What software will be in- 
cluded? Answer: We intend to provide a 
monitor/debugger, assembler, and ap- 
plications, hopefully including source 


“Intro to Packet Radio” 


Now Available 


Larry Kenny, WB9LOZ, is NCPA’s education 
coordinator and his well-known series of bulletins 
“Introduction to Packet Radio” has helped many a 
ham to get started in packet. Now Larry’s articles 
are available to you in print! Newly updated, typeset 


and bound, this collection of articles can be referred 
to again and again as you explore the many facets 
of packet radio. To order, send $5 (price includes 


postage) to: 


Northern California Packet Association 
6680B Alhambra Ave. Suite 111 
Martinez, CA 94553 


code. The intention is to provide the 
tools required for code hackers, AND at 
least a minimal set of modems and packet 
applications for operators. One member 
of the software team is into images, so 
expect an SSTV application. Another 
member proposes to create a spectrum 
analyzer. 


Question: How much compatibility 
will there be between this board and the 
other platforms announced by vendors? 
Answer: Not much. There are sig- 
nificant differences, such as a different 
DSP processor, The algorithms will be 
the same, but the code will have to be 
rewritten. There is a European group that 
has a small board based on the DSP56001 
used by the other vendors; they have 
implemented a bit-banging HDLC driver 
on the DSP chip. 


Question: I wantto plug in my scanner 
and receive 9600 bps broadcasts. How 
do I get this done by a certain date? 
Answer: mumble mumble. 


Question: What baud rates will the 
DSP board be able to support? Answer: 
It should be able to handle FSK up to 
9600 bps with no problem. Nobody’s 
quite sure if it’Il handle something fancy 
like a V.29 modem at 9600 bps. Com- 
ment: Telebit Trailblazers use this 
processor, and they do V.29. 

Question: Can the board be sped up? 
Answer: Yes. It’s designed to go 40 
MHz, You just need to plug in faster 
parts. The limit will probably be the 


PALs, which need to be 7ns parts to go 
40MHz. N3EUA: With faster DSP you 
may be able to get a 2X speedup, but 
you’ ll never get another order of mag- 
nitude speedup. You have to choose a 
performance class and build the best 
solution for that class. 


Question: What range of sampling 
rates can it handle? Answer: Up to about 
400 kHz. A fast sample rate like this is 
useful for non-modem applications, like 
spectrum analyzers. That was one 
reason for choosing 8-bit I/O instead of 
more precise, slower converters. 


Question: How much power does it 
require? Answer: No measurements have 
been made yet, but only two chips on the 
board get noticeably warm. Guess: less 
that 5 watts. 


Question: Other than DSP software 
gurus, are volunteers needed to help with 
the DSP project. Answer: No. 


Harold Price, NK6K 
Honored 


Lyle Johnson, WA7GXD, presented a 
plaque to Harold Price, NK6K, for his 
contributions to packet radio since 1982. 
In accepting the award, NKG6K said that 
he sees himself as a link between the 
experimenters on the forefront of tech- 
nology and the users of the technology. 


Continued in the next issue... 
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Northern California Packet Association 
NCPA Board of Directors 


Meeting Minutes 


Meeting of January 13, 1991 


The NCPA Board met on January 13, 1991 at 
General Parametrics in Berkeley. Present at this 
meeting were the following board members: 
WA8DZP WD6CMU KA6ETB KB6OWT WBSLOZ 
N6QMY 


Also in attendance were: AA4RE K3MC 
W6VOM KC600M KB6TKL N6VOM 


Business 


1. Pat N6QMY made the treasurer’s report. 
The current balance in the organization's account 
is $2,012.33. No progress has been made as yet 
on the incorporation of NCPA. K9AT has offered 
to help get this expedited. 


2. Dewayne WA8DZP made the secretary's 
report. There are currently 340 members of 
NCPA. We are currently in the process of deter- 
mining how many members of the organization are 
ARRL members so that we can apply to become 
an ARRL affiliate organization. He reported that 
we have been in violation of USPS regulations as 
to how we have been mailing out the newsletter. If 
metered postage labels are used inthe future, then 
the newsletters must be mailed from the post office 
indicated in the stamp. 


3. Mike K3MC made the Newsletter Editor's 
report. The current newsletter will be Mike's last. 
He directed the Board to look for a new newsletter 
editor. Mike asked the Board to allow past issues 
of the Downlink newsletter to be posted to the 
Internet so that it could be made available to the 
public at large. A motion to this effect was made 
and passed by the Board. Future issues will be 
posted three months after release to the Internet. 


4. Roy AA4RE made the Frequency 
Coordinator's report. He discussed the NCPA 
proposed 220 MHz Band Plan for the FCC-man- 
dated changes to the 220 MHz Band. He proposed 
an across the board cut of 40% in the number of 
channels. Everything below 222 MHz has to go. 
This means that we will lose one LAN channel. 
The DXPSN will have to move from 221.4. 


WDECMU was tasked with writing a letter to the 
DXPSN people to ascertain their plans for the loss 
of 220-222 MHz. WAGAEO feels that we can trade 
the 430 MHz channels for space in 420 MHz which 
is not used. AA4RE will be contacting NARCC to 
discuss our band plans. 


5. Fred K6RAU, the PBBS Coordinator was 
not present, so there was no PBBS report. 


6. Larry WB9LOZ made the Education 
Coordinator's report. NCPA will co-host an intro- 
ductory packet seminar with Kantronics which will 
occurin May. The Board authorized the printing of 
500 copies of Larry's “Introduction to Packet 
Radio,” which will be sold for $5 per copy. 


7. Steve KA6ETB made the Emergency 
Coordinator's report. He received no response to 
his bulletin requesting assistance on coordinating 
with other existing services or emergency or- 
ganizations. 


8. NCPA has been chosen by the ARRL to 
host the 10th ARRL Amateur Radio Computer 
Networking Conference. The dates for the event 
will be September 27-29. 


9, Mike K3MC reported that Glenn AAGER has 
agreed to be the “interim” newsletter editor. 


10. The tentative date of the next General 
Membership meeting was set for March 3{st. Eric 
WDE6CMU will arrange for a meeting place. The 
deadline for agenda items for this meeting will be 
February 15th. A notice of the meeting will be 
mailed at the end of February. 

11. A short discussion on a replacement for 
the forwarding backbone resulted in the decision 
that this was an NCXPN issue, which should be 
referred to them. 

The meeting concluded as there was no further 
business. The board did not meet in closed ses- 
sion. 


Dewayne Hendricks WA8DZP 
NCPA Secretary 


EOF 


FCC Report and Order 


on 220Mhz 


From the ARRL Bulletin 15 


The FCC on March 14 issued a report and order in PR Docket 89 


552, adopting rules for the use of 220 to 222 MHZ by the Private 
Land Mobile Service. Amateurs will be required to discontinue 
all operations in the 220 to 222 MHZ band 90 days after the 
effective date of these rules, which has not yet been announced. 
Amateurs probably will have to vacate the 220 to 222 MHZ part 
of the band in late July. 


NCPA Directors 


Eric Williams, WD6CMU 
WD6CMU @ WD6CMU 
415-237-9909 


Chris Marley, NGRAL 
N6RAL @ N6IIU 


Michael Bothe, KBGOWT 
KB60WT @ K3MC 


Steve Harding, KA6ETB 
KA6ETB @ N6LDL 


Patrick Mulrooney, NGQMY 
N6QMY @ N6QMY 


Dewayne Hendricks, WA8DZP 
WA8DZP @ K3MC 


Larry Kenny, WB9LOZ 
WB9LOZ @ W6PW 


NCPA Officers 


President: 
Eric Williams, WD6CMU 
WD6CMU @ WDSCMU 


Vice-President: 
Michael Bothe, KBEOWT 
KB6OWT @ K3MC 


Secretary: 
Dewayne Hendricks, WA8DZP 
WA8DZP @ K3MC 


Treasurer: 
Patrick Mulrooney, NSQMY 
N6QMY @ N6QMY 


Newsletter Editor: 
Glenn Tenney, AAGER 
AAG6ER @ K3MC 


Frequency Coordinator: 
Roy Engehausen, AA4RE 
AA4RE @ AA4RE 
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Where to Find a BBS 


NOARY-1 
KE6BX 
KJ6FY-1 
Ki6YK 
WD6CMU 
N6EEG 
W6FGC-2 
K6LY 
N6LDL 
KIGWE 
KD6XZ-1 
AA4RE-1 
KA6FUB 
N60A 
W6PW-3 
WA6RDH 
KG6EE 
KI6EH 
N6IIU-1 
KE6LW-1 
KG6XX-1 
W6CUS-1 
N6ECP 
KB6IRS 
N6IYA-2 
K3MC 
WA6NWE-1 
K6RAU-1 
WA6YH4J-1 
W8GEC 
WA6HAM 
KB5IC 
KA6JLT-2 
N6MPW 
WB6ODZ-1 
N6QMY-1 
N6REB-2 


Sunnyvale 
Hollister 
Benicia 
Danville 
Richmond 
Berkeley 
Twain Harte 
Monterey 
Los Gatos 
Pleasant Hill 
Sacramento 
Gilroy 
Martinez 
Lemoore 
San Francisco 
Dixon 

Santa Cruz 
Santa Cruz 
Palo Alto 
Yuba City 
Carmichael 
Richmond 
Redding 
Soquel 
Felton 
Fremont 
North Highlands 
Merced 
Livermore 
Boulder Creek 
Pittsburg 
San Jose 
Menlo Park 
Ben Lomond 
Lake Isabella 
Fremont 
Modesto 


144.93 
144.93 

144.93 

144.93 

144.97 

144.97 

144.97 

144.97 
144.97, 145.71! 
144.97 
144.97, 441.50 
144.99 

144.99 

144.99 

144.99 

145.01 

145.07 

145.07 
145.07, 223.56 
145.07 

145.07, 441.50 
145.09 

145.09 

145.09 

145.09 

145.09 

145.09, 441.50 
145.09 

145.09 

145.73 

145.73 

145.73 

145.73, 145.71! 
144.79 
145.797 
145.79 

145.79 


‘Experimental 9600 baud port, subject to change 


May be off-line due to remodeling 


The Band Plan 


No channelization has been done for these 


bands. Some activity is present. 
903-905 Mhz 

915-917 Mhz 

1248-1252 Mhz 

1297-1300 Mhz 


50MHz 
51.12 SOCAL backbone 
51.14 relat tab ae 
51.16 Kybd to Kybd 
51.18 Experimental 
144MHz 
144.91 keybpard-to-keyboard 
144.93 LAN 
144.95 DX Spotting Network 
144.97 LAN 
144.99 LAN 
145.01 keyboard-to-keyboard 
145.03 keyboard-to-keyboard 
145.05 keyboard-to-keyboard 
145.07 LAN 
145.09 LAN 
145.71 9600 baud TAPR compatible 
145.73 LAN 
145.75 TCPAP 
145.77 DX Spotting Network 
145.79 LAN 
146.58 DX Spotting Network 
‘Used by TCP/IP in the Sacramento area 
220 MHz 
220.80-220.89 Experimental 
220.90 Superbackbone 
220.91-221.00 Experimental 
221.04 DX Backbone 
223.42 node uplink (SBAY) 
223.52 node uplink (NBAY) 
223.54 node uplink (EBAY) ; 
223.56 keyboard-to-keyboard 
223.58 node uplink (“Other”) 
223.60 node uplink (SACVAL) 
‘Shared with BBS forwarding in Monterey Bay area 
430 MHz 
100KHz-wide channels 
433.05 TCP/IP 
433.15 NET/ROM backbone 
433.25 DXPSN backbone 
20KHz-wide channels 
433.31 backbone 
433.33 backbone 
433.35 backbone 
433.37 backbone 
433.39 backbone 
433.41 LAN interlink 
433.43 9600 baud TAPR compatible (pending) 
433.45 cite experimental & backbone 
433.47 NET/ROM interlink, keyboard 
433.49 TCP/IP 
441.50 all 


te i 
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= NCPA, the Northern California Packet Association, is an organization formed to 
: foster the Digital Communications modes of Amateur Radio. So far, we have 
; defined our goals as: 


WM Education 
Hi Coordination 


Education means making information available about various Digital modes, and 
this newsletter is but one part of that education process. 


Coordination activities include frequency coordination (NCPA is recognized by 
NARCC as the official packet radio frequency coordinator) as well as coordinating 
people and their various uses of packet radio, be they DX Cluster, BBS, TCP/IP, 
keyboard-to-keyboard, NET/ROM, Traffic/NTS, Emergency uses of packet, or even 
experimenting with new frontiers of various digital modes. 


We in NCPA believe that the next revolution in Ham Radio will come about in Digi- 
tal Communications Technology, and in the beneficial coordination among all 
users of ham Digital Communications Technologies. 


We invite you to join NCPA! Become part of the most dynamic group of packet 
folks in Northern California! 


SSeS eo SS unaecneri 


NCPA Downlink 


Northern California Packet Association 
6680B Alhambra Ave. Suite 111 
Martinez, CA 94553 


First Class Mail 


